COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASB30\M3NGR25\M4NGR20\M5BASI30
C00018 ENDMK
C⊗;
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\M5BASI30;
\F1\CJan 25, 1980



Mr. Michael Riggs, Associate Editor
Mini-Micro Systems
221 Columbus Avenue
Boston MA 02116

	

Dear Mr. Riggs:

\JEnclosed is my completed questionnaire for your April issue; thank
you for including LISP in your survey.  Frequently one finds a certain
misconception that LISP is a special purpose language for 
Artificial Intelligence research, requiring massive
mainframes  to support it, and has a greedy appetite for machine cycles.
In the next few paragraphs I will try to dispell some of those myths,
and if you are sufficiently intrigued, would consider writing an article
about the uses of LISP in "real" computing.

First, LISP is the second oldest programming language, being second only to
Fortran in longevity. The initial implementation was done on the IBM 704
and was the standard until the PDP-6 (aka PDP-10) appeared in 1964.
The machine specifications for the 704 read today like a poor micro!

Second, LISP's reputation as a special-purpose language is grossly
unfair. Even the first version of LISP contained full arithmetic, arrays,
and a compiler --three trappings usually attributed to "general purpose"
languages. Of course LISP also had (and has) several more modern features:
full symbolic data structures, dynamic allocation (garbage collection
was invented by the LISP team), procedures as data objects (again, the
general implementation strategy for this feature was invented by the LISP
team). Of course in 1958, LISP didn't do \F5everything\F1 -- it had no string
objects per se -- one could implement strings as lists of characters, but ...

As  a programming methodology, LISP offered the first "object-oriented" language,
meaning that one could talk about data items as abstract objects, independent
of their implementation. This freed the programmer from the tedious details
of storage management. Garbage collection, and the generalized data construction
operation, \F5cons\F1 are largely responsible for that. People are quick to
point out that LISP has the dreaded \F5goto\F1; they should also be aware
that the initial 704 LISP  had the equivalent of the \F5case\F1 statement, one 
of the trappings of a "modern language".
They should also realize the "record structures" were present in the first LISP.
They are called "property lists" and can be dynamically expanded and 
contracted during the execution of the program.
Of course, these  comments refer to the earliest of LISP days. LISP
came into its own with interactive programming (one of the earliest
demonstrations of time-sharing was that of running LISP on the 704 at MIT).

LISP is a very interactive programming language. The programming style
of AI has been called "middle-out" rather than "top-down" or "bottom-up".
This means that one tends to write (on-line) function modules; test them
interactively; and when satisfied, write more, putting the blocks together
as one creates larger modules. One thinks  of  a modern LISP as a "programming
environment" in which one creates and nutures program segments. Due to the
interactive nature of the beast, one can begin to program effectively
without having totally specified algorithms. 
Within the LISP environment an attempt to execute
undefined code, or access undefined data, will illict an
online error message and suspend the computation. The user
is free to supply values, modify the offending code or data, or
abort the computation. This flexibility is most elegantly supported
by LISP's unique representation of program as data. Briefly (and somewhat
simplistically), LISP's internal representation for programs is a "parse
tree", showing explicitly the interrelationships between the program elements.
Since this representation  is a data item of LISP, it becomes trivial to write
LISP editors, debuggers, interpreters, and compilers for LISP in LISP itself.
(Note: it is important that the internal representaion reflect the structural
interrelationships when building such programs; for example, representing
program text as strings or arrays of characters is unacceptable. Program
mainpulation programs \F2must\F1 be able to find components and sub-components
of programs rapidly). As one example, LISP was the first language to produce
its compiler by writing the compiler in LISP and asking it to compile
itself. Since that time, all LISP compilers have been constructed this way.
These compilers tend to be as good as those produced for any other language;
in a famous test, the MACLISP compiler produced better code (both in space
and speed) than the
then-current 
DEC Fortran compiler. This was on a completely numerical algorithm, refuting
the myth that LISP, and LISP arithmetic in particular, need be slow.

LISP is "type-free", meaning that
the restrictions of data declarations are not required. One can simply
write programs and try them.  Of course, interactive program construction
and declaration-free programming are not in vogue now.  Current "scripture"
says that discipline is required when writing programs, and that discipline
must be enforced by the language. Not being into  "B & D", I would disent,
saying that indeed discipline must be practiced, but that discipline must
come from the programmer. One must educate and train programmers much like one
trains members of any other craft. To restrict the craft's tools is like
removing the fine "hone" from a carpenter's plane so that the apprentices
won't cut their fingers.  The second  point is that AI programming, in general,
does not involve coding well-defined  algorithms; one is trying to capture
 a partially understood phemomenon by encoding one's current understanding
of the problem and seeing how well the program performs. This process
is incremental and experimental. One cannot expect a closed form
description of the solution, including declarations, all written out
to be typed into the machine and executed. Further, one cannot expect
to program within a system that required a total recompilation of the
world whenever a modification is required. Even in "real life" we don`t
act that way: when we plan a trip, we have a general outline of where we
intend to go; when something unexpected occurs on the trip, we don't
high-tail it back home and replan; we modify our behavior and continue.
Surely, we should expect that much from a programming system.

Of course, freedom can be misused; but, it is up to the individual to 
impose self-discipline. It is up to the system to supply the appropriate
tools to support and reinforce mature behavior; as a programming tool,
it is \F2not\F1 appropriate to attempt to require it.

...But enough. It should be clear that LISP represents a "non-standard"
view of computing.  I would argue that this view is more attuned to 
the expectations of interactive, personal computing, and systems-building 
schools  than the view 
espoused by the "edit-compile-run-debug-and-iterate" school.

The questions are: can such a language/programming system be accomodated
within the confines of a micro computer, and what kinds of applications
can be expected to profit from the generality supplied by LISP?

The first question is easy: several versions of LISP are available on 
micro-computers. We happen to think that TLC-LISP is the best.
It is a subset of the MIT LISP Machine LISP (see Mini-micro June 1978,
I believe). It is a very elegant LISP, suitable for extension to 
the sixteen-bit machines; a short description is enclosed. 
We didn't put in arrays yet, but that is a
trivial extension to the system, requiring perhaps 2 days of effort.
Probably by your April issue, arrays will exist; we also expect to have a
compiler by that time. A lot of our effort is going into the selection
of the next LISP project right now, so coding has taken a back seat
to proselytization (sp?).

LISP applications are extensive. Besides the traditional domains for programming
languages, LISP excells in "non-numerical" computations. For example,
many LISP's offer "arbitrary precision" arithmetic, meaning that the arithmetic
is not restricted by the word-size on the underlying machine (such a system,
running on a Z-80 can compute 100-factorial in less than 3 seconds --hum, maybe
5 seconds; the reference is in the August 1979 BYTE: Stoutemyer's article).
One can also represent algebraic quantities in LISP's data structures and
thereby build "algebra calculators" much like current arithmetic calculators,
except that one has operations like "simplify", "collect like terms",
"sum these polynomials", etc.  

As you can probably tell by this letter, I am composing it right now!
I have a meeting in 10 minutes, but wanted to get this and the questionnaire
to you before the deadline. I hope this isn't too jumbled; I hope it
sheds some light on the LISP issue. If you'd like clarification or elaboration,
please give me a call (a: after Jan 31, and b: persistence is necessary).
\.


\C ...And by the way!!! 

\JI have lost my free subscription to your magazine
since going into my own business. That really irritates me! I happen to think
that my current position is as valuable as that held at HP and Signetics;
and I also happen to think your magazine is the \F5best\F1 of those I
used to receive. Yes, don't feel too bad; all the magazines and newspapers
were "fair weather" friends (Oh, ye of little faith!!!). Please
try to get me reinstated; I need the information in your pages to keep
current in my business.
\.
\←L\→S\←R\-L\/'2;\+L\→L

Yours sincerely,


John R. Allen
Founder, The LISP Company
18215 Bayview Dr.
Los Gatos Ca, 95030
(408) 353-3857

\←S\→L